Date: Fri,  1 Oct 93 04:30:24 PDT
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V93 #60
To: Ham-Digital


Ham-Digital Digest          Fri,  1 Oct 93       Volume 93 : Issue   60

Today's Topics:
                 32 bit versions of NET/NOS for OS/2?
                                <none>
                    BAYCOM does not run under OS/2
                          HF Packet (2 msgs)
                Kenwood TS-950SD customer satisfaction
                       Looking for PCMICA radio
                       MULTICOMM V3.0 (2 msgs)
                        Need advice in Germany
                          Packet Monitoring
                        packet radio encrypti
               PD OS/2 TCP/IP stack development effort

Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 28 Sep 93 20:10:11 GMT
From: library.ucla.edu!news.mic.ucla.edu!magnesium.club.cc.cmu.edu!pitt.edu!dsinc!spool.mu.edu!howland.reston.ans.net!usc!news.service.uci.edu!unogate!mvb.saic.com!logjam!jcp@network.ucsd.
Subject: 32 bit versions of NET/NOS for OS/2?
To: ham-digital@ucsd.edu

   I'm wondering what versions of KA9Q NET/NOS are available for OS/2. Of
course one can run any of the MS-DOS versions in a DOS session, but I'm
most interested in 32 bit OS/2 versions. I've experimented some with the
PM version by KZ1F (see ucsd.edu:/hamradio/packet/tcpip/os2/pmnos1dx.zip).
What else is out there for OS/2? Sorry if this has been discussed before,
I will summarize if there is interest.

73's John

-- 
John C. Peterson  KD6EKQ       | + 1 619 546 6539 | Disclaimer: The opinions
Science Applications Intl Corp | jcp@trg.saic.com | expressed are mine alone,
10260 Campus Point Drive MS-C6 |                  | and do not reflect those
San Diego, CA 92121            |                  | of SAIC.

------------------------------

Date: 30 Sep 93 01:37:02 GMT
From: swrinde!gatech!pitt.edu!dsinc!spool.mu.edu!uwm.edu!ESAMATC.LIB.MATC.EDU@network.ucsd.edu
Subject: <none>
To: ham-digital@ucsd.edu

In the Southeastern Wisconsin area, we are trying to upgrade the
backbone from 4800 baud to 9600 baud.  My problem is, a Kantronics data
engine, an MFJ 1274, an MFJ 9600 baud modem, a deviation of 3 KHz. all
at about 200 ft. doesn't work!  4800 baud works fine!

We are using Icom 3200's as part of the 9600 baud network.  They talk
to each other!

I'm open to any suggestions to get this Kilobuck project resolved.  We
don't have a path problem, this isn't working on the bench!  Is there
something I've overlooked?

Has anyone had problems with the Data Engine?

73, Nels....

Nels Harvey, WA9JOB,           Chairman, Wisconsin Assoc. of Repeaters
Television Engineer               E-Mail:  NHAR@MUSIC.LIB.MATC.EDU
WMVS/WMVT Milwaukee            Packet: WA9JOB@WA9POV.GRAFTON.WI.USA.NA
Milwaukee Area Technical College      Phone:  (414) 271-1036
Milwaukee, WI   53233-1443            Fax:    (414) 225-1895

------------------------------

Date: 30 Sep 1993 15:18:48 GMT
From: library.ucla.edu!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!ux2.cso.uiuc.edu!ignacy@network.ucsd.edu
Subject: BAYCOM does not run under OS/2
To: ham-digital@ucsd.edu

I can't get BAYCOM to run under OS/2. I tried many options in the DOS
window. Under OS/2, BAYCOM never receives any packet, and it
terminates due to illegal instruction

I prefer to run BAYCOM under OS/2 because the computer is not tied
up.

If possible, please respond to the address below.

Ignacy Misztal, NO9E, SP8FWB
ignacy@uiuc.edu

------------------------------

Date: Wed, 29 Sep 1993 20:25:22 GMT
From: news.uiowa.edu!panda@uunet.uu.net
Subject: HF Packet
To: ham-digital@ucsd.edu

My HF packet station is now on the air. Can someone please advise me as to the 
preffered way to make contacts with other ops not BBSs. Also other than 14.1 
Mhz where does HF packet operate?
Tnx
Scott -- KF5JQ

------------------------------

Date: Thu, 30 Sep 1993 15:07:08 GMT
From: library.ucla.edu!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!panda@network.ucsd.edu
Subject: HF Packet
To: ham-digital@ucsd.edu

Sorry about posting this three times but I was having trouble with the server. 
It kept giving error messages but it looks like it sent the posts anyways. 

------------------------------

Date: 30 Sep 93 13:22:55 GMT
From: news-mail-gateway@ucsd.edu
Subject: Kenwood TS-950SD customer satisfaction
To: ham-digital@ucsd.edu

Back in December 1992 I submitted this letter to the Correspondence Section of
QST after reading the review of the TS-950SDX.

In the opening paragraph of the Kenwood TS-950SDX review (December 92 QST) Rus
Healy states " It had better be something really special, you're thing,
otherwise Kenwood would have alot of explaining to do as why they released this
rig less than two years after its predecessor!"

Well, I am one of many Hams who bought a TS-950SD and would like to have an
explanation from Kenwood.  Was the TS-950SD a field test or a marketing probe?
Were they working on the TS-950SDX and need to release a earlier version due to
competition?

Lets hope customer satisfaction and customer loyalty is still the most
important product a company like Kenwood could produce.

 ---end of letter to QST---

Let me know if you have any ideas on what I can do...  Maybe getting a
list of all known TS-950SD owners on the net and all on the same day send a
letter to Kenwood complaining about this problem.  If they get enough
letters in one week maybe they would notice!

Paul  KW1L
Paul_Adler.NER-OSM@xerox.com

------------------------------

Date: Thu, 30 Sep 1993 11:14:09 -0400
From: library.ucla.edu!agate!howland.reston.ans.net!math.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!bb3.andrew.cmu.edu!andrew.cmu.edu!ll2c+@network.ucsd.edu
Subject: Looking for PCMICA radio
To: ham-digital@ucsd.edu

I hope this is the right place to post this message.  Right now I am
working on a research project.  But I run into to trouble in finding the
components that I need.  Does anyone know where I can find a PCMICA two
ways radio or fax/data modem that consumes very little power?  If you
do, can you tell me where I can find the specification on those parts.
 
Thank you
 
-Lok

------------------------------

Date: Thu, 30 Sep 1993 07:09:04 GMT
From: munnari.oz.au!bunyip.cc.uq.oz.au!un!gc034@uunet.uu.net
Subject: MULTICOMM V3.0
To: ham-digital@ucsd.edu



------------------------------

Date: Thu, 30 Sep 1993 07:29:12 GMT
From: munnari.oz.au!bunyip.cc.uq.oz.au!un!gc034@uunet.uu.net
Subject: MULTICOMM V3.0
To: ham-digital@ucsd.edu



------------------------------

Date: Thu, 30 Sep 1993 00:36:10 GMT
From: dog.ee.lbl.gov!agate!howland.reston.ans.net!xlink.net!fauern!news.dfn.de!gwdu03.gwdg.de!amatthi1@network.ucsd.edu
Subject: Need advice in Germany
To: ham-digital@ucsd.edu

Hi,

I want to begin setting up an amateur radio system and I need some
advice and guidance from someone who has some experience with these
things and who would like to answer some questions via e-mail.
German contacts preferred, because I also have questions about obtaining
the right equipment in Germany ( sources, prices etc)

Thanks, Andreas

PS. Please answer to andreas_matthias@rollo.central.de if possible.

------------------------------

Date: 29 Sep 93 18:41:39 GMT
From: swrinde!gatech!pitt.edu!dsinc!spool.mu.edu!howland.reston.ans.net!agate!netsys!pagesat!ukma!eng.ufl.edu!usenet.ufl.edu!mailer.cc.fsu.edu!freenet.scri.fsu.edu!bischoff@network.ucsd.edu
Subject: Packet Monitoring
To: ham-digital@ucsd.edu

I am a newcomer to packet and want to start out just "reading the
mail" for a while.  I am using the simple interface that Bill
Nolle sells and a AT class pc.  My question is: can anyone
suggest some decent software I can use to first monitor and later,
once I get the hang of packet, to Tx as well??  I have PKTMON now
which allows pure monitoring but I'd like something simple (if 
possible) which will TX too.
Part II - I have an old Azden PCS4000 2 meter rig which I'd like
to use for my packet.  Can anyone give any tips re the interfacing
for this rig??  Any help would be much appreciated.
-- 
Bill Bischoff, NK4O    |
3691 Dexter Drive      |  bischoff@freenet.scri.fsu.edu
Tallahassee, Fl 32312  |
(904) 893-6547         |

------------------------------

Date: 30 Sep 93 06:23:00 GMT
From: news.crd.ge.com!rpi!usc!howland.reston.ans.net!agate!iat.holonet.net!n0lqt@cs.rochester.edu
Subject: packet radio encrypti
To: ham-digital@ucsd.edu

        What everybody in the "digital encryption vs compression
  schemes" debate seems to miss is that the rules on encryption  
  were written by Lawyers not Technicians.

        In the United States, Part 97.113.d states in part:

     (d) No station shall transmit: music; radiocommunications or 
     messages for any purpose, or in connection with any 
     activity, that is contrary to federal, state, or local law; 
     messages in codes or ciphers where the intent is to obscure 
     the meaning (except where specifically excepted elsewhere in 
     the Part);...

        I think this has been said before, but it bears 
  repeating.  A CODE IS A CODE ONLY IF YOU USE IT TO HIDE WHAT 
  THE MESSAGE IS SAYING.

        The key word in this section is "INTENT"  Under the law, 
  intent is of utmost importance.  If I transmit a message, in 
  CW, Voice, AMTOR, Packet, Clover, or whatever, if I do not 
  intend it to mean something other than what it says then it 
  isn't a code.  No matter in what mode it is sent or what
  compression schemes or encoding are used to facilitate sending it.
  If I wanted to take all the message traffic off my PBBS and 
  compress it with PKZIP, UUENCODE it, and then send it by TCP/IP 
  SMTP with LZW compression, using CW, that is legal.  As long as 
  my "INTENT" was not to obscure the meaning.  State of mind must 
  be shown in any prosecution of this section.  The FCC must be 
  able to show "to a reasonable person" that is was in my mind that 
  the above process would obscure the meaning of the messages so as 
  to hide their meaning.

        If, on voice, I call you and say "Hi Jim!  The sun sure is 
  bright today, do you think it will rain?"  If that is what I 
  meant, then all is well.  If, on the other hand, I had agreed with 
  you that when I asked that it meant, "Meet me at the Coffee Shop 
  at the corner of Third and Ash Street in 15 minutes, I've got some 
  juicy gossip to tell you."  Then that is a code and is illegal.  
  If I wrote that in a message and compressed it before sending and 
  sent it to you via packet, the same rules apply.  If I sent you 
  14 different messages each with one word in them and numbered 
  consecutively and you had to reassemble them at your end, as 
  long as my "intent" was not to obscure or hide the meaning of 
  the messages, then that is not a code and is legal, at least 
  here in the USA it would be.  Not saying that I wouldn't have a 
  lot of Hacked Off Sysops sending me Flamethrower-grams in 
  return for clogging up the network.  But that is a different 
  thread!

                                               Seeyaalllaterbye...  JoeP.
     de N0LQT (Joe Palmer) from Newton, Ks. 67114 On a TCP/IP Network BBS

 EMAIL Addressing:
  Packet: n0lqt@n0lqt.#scks.ks.usa.na  LLBBS: Joe Palmer @ (316)-284-2421
  Compuserve: Joe Palmer (73327,760)   InterNet: n0lqt@holonet.net
=========================================================================
 
... Even Paranoids have Enemies!
___ Blue Wave/QWK v2.12

------------------------------

Date: 30 Sep 93 14:06:07 GMT
From: ogicse!uwm.edu!cs.utexas.edu!swrinde!dptspd!news@network.ucsd.edu
Subject: PD OS/2 TCP/IP stack development effort
To: ham-digital@ucsd.edu

 Several have asked me to pass on the address of the group for development
of a public domain tcp/ip stack for OS/2.

The group is:	os2ip@its.flint.umich.edu

Try subscribe to os2ip-request@its.flint.umich.edu

There has been a recent flurry of discussion about what NIC Driver
standard to use (NDIS/ODI/etc...) and about driver construction in
general....

Jack Spitznagel
TeamOS/2

------------------------------

Date: Wed, 29 Sep 1993 20:33:56 GMT
From: dog.ee.lbl.gov!agate!howland.reston.ans.net!gatech!kd4nc!ke4zv!gary@network.ucsd.edu
To: ham-digital@ucsd.edu

References <gila005-260993180054@right.dom.uab.edu>, <1993Sep28.133539.13214@ke4zv.atl.ga.us>, <gila005-280993153533@right.dom.uab.edu>
Reply-To : gary@ke4zv.UUCP (Gary Coffman)
Subject : Re: 9600 baud radio setup

In article <gila005-280993153533@right.dom.uab.edu> gila005@uabdpo.dpo.uab.edu (Steve Holland) writes:
>In article <1993Sep28.133539.13214@ke4zv.atl.ga.us>, gary@ke4zv.atl.ga.us
>(Gary Coffman) wrote:
>> QAM will work over radio, but you need good signals at both ends and 
>> a well characterized system frequency and amplitude response. The
>> training sequences used on duplex telco circuits don't work on a
>> half duplex channel so you have to use fixed equalization. That is
>> likely to only work well between a specific pair of stations. On
>> the other hand, you don't have to worry about echo cancellation.
>
>I was looking at some spec sheets on 9600 baud chip sets, and I noticed
>that there was a training mode. Does each modem train itself by listening
>to it's own signal on the line coming back on landlines?  Might
>it be possible to set up a system where part of the initial connect
>sequence includes some training as part of a protocol, say like start
>a packet qso at 1200, then exchange training signals for 9600, confirm
>at 1200 all was OK, then go to town?

The Japanese have been using a FAX/modem chip for packet for a while.
TAPR did some work with it as well. As I understand it, the chip
does a training sequence automatically each time it starts a transmission.
Since that's every packet, and the training sequence is several seconds
long, and requires a cooperative duplex response from the other end, it's 
pretty useless that way. There is a "test" mode you can force the chip into 
where it doesn't do training. That works, but then you're back to external 
fixed equalization. So it appears that what you want could be done, but 
there's no off the shelf phone chip that will do it.

Gary
-- 
Gary Coffman KE4ZV          |"If 10% is good enough | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems | for Jesus, it's good  | uunet!rsiatl!ke4zv!gary
534 Shannon Way             | enough for Uncle Sam."| emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     | -Ray Stevens          | 

------------------------------

Date: 30 Sep 93 12:53:03 GMT
From: newsgate.watson.ibm.com!hawnews.watson.ibm.com!news@uunet.uu.net
To: ham-digital@ucsd.edu

References <1993Sep27.175914.10643@news.mentorg.com>, <1993Sep28.190214.9045@mnemosyne.cs.du.edu>, <1993Sep28.230042.16132@ke4zv.atl.ga.us>
Reply-To : pcr@vnet.ibm.com (phil reed)
Subject : Re: Responsibility for BBS messages

In <1993Sep28.230042.16132@ke4zv.atl.ga.us> gary@ke4zv.atl.ga.us (Gary Coffman) writes:
>In article <1993Sep28.190214.9045@mnemosyne.cs.du.edu> lkollar@nyx.cs.du.edu (Larry Kollar) writes:
>>
>>In another message, Gary McDuffie compares forging a call on packet to
>>using a bogus call on a repeater.  However, repeaters are not assumed
>>to be running unattended (like most packet BBSes/forwarding nodes).
>>[Or are they?  Oh well, I'm sure I'll hear about it if I'm wrong. :-)]
>
>Hint, 97.205(d).
>
>Gary

Is the entire text of Part 97 available someplace for FTP?


                     ...phil
-----------------------------------------------------------------------------
 phillip c. reed
  pcr@vnet.ibm.com / KD4PWI@N4YUU.CKY.KY.USA.NA / CI$:72754,513
* It is highly unlikely that the opinions expressed herein are those of IBM *
*   or any of it's operating units.                                         *

------------------------------

End of Ham-Digital Digest V93 #60
******************************
